2026年第一天的杭州天气不佳，没有外出拍照……
Always Day One
这个世界有很多成功的公司都崇尚“永远是第一天”的理念，比如Amazon， Facebook， ByteDance，这些理念都强调了持续创新和保持创业精神的重要性。
还有一些公司在重要决策的时候，都会借用类似的“如果今天是公司的第一天，我们会怎么做？”这样的问题来帮助自己保持初心，避免陷入惯性思维。比如Intel 当年果断放弃了内存业务，专注于微处理器的发展。
以终为始，背后的逻辑应该也是类似的。
Bin-Weekly 也践行一下Day 1。2026年从头开始，2026年之前的归档留在了：https://w25.jibin.net
在这个新年第一天特别的日子里面，仅以 “Always Day One” 作为自我激励。
2025年的划词分享
以下是2025年个人微信读书的划词分享，分享给大家。
《代码整洁之道：程序员的职业素养》
Robert C. Martin
第1章 专业主义
◆ 做个非专业人士可轻松多了。非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。如果非专业人士把事情搞砸了，收拾摊子的往往是雇主；而专业人士如果犯了错，只好自己收拾残局。
◆ 不，我其实是想告诉你，要对自己的不完美负责。代码中难免会出现bug，但这并不意味着你不用对它们负责；没人能写出完美的软件，但这并不表示你不用对不完美负责。
◆ 要想证明软件易于修改，唯一办法就是做些实际的修改。如果发现这些改动并不像你预想的那样简单，你便应该改进设计，使后续修改变简单。
◆ 这完全与大多数人对软件的理解相反。他们认为对上线运行的软件不断地做修改是危险的。错！让软件保持固定不变才是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”。
◆ 你应该计划每周工作60小时。前40小时是给雇主的，后20小时是给自己的。在这剩余的20小时里，你应该看书、练习、学习，或者做其他能提升职业能力的事情。
◆ 一周有168小时，给你的雇主40小时，为自己的职业发展留20小时，剩下的108小时再留56小时给睡眠，那么还剩52小时可做其他的事呢。
◆ 那20小时是为你自己的。它们将会让你成为更有价值的专业人士。
◆ 软件行业的飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍。不写代码的架构师必然遭殃，他们很快会发现自己跟不上时代了；不学习新语言的程序员同样会遭殃，他们只能眼睁睁看着软件业一路发展，把自己抛在后面；学不会新规矩和新技术的开发人员更可怜，他们只能在日渐沦落的时候看着身边人越发优秀。
第2章 说“不”
◆ 奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。事实上，优秀的经理人对于敢于说“不”的人，总是求贤若渴。因为只有敢于说“不”，才能真正做成一些事情。
第4章 编码
◆ 软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。专业程序员也会同样仔细地保存好自己的精力和创造力。
《卓有成效的管理者》
彼得·德鲁克
为什么需要卓有成效的管理者
◆ 我们无法对知识工作者进行严密和细致的督导，我们只能协助他们。知识工作者本人必须自己管理自己，自觉地完成任务，自觉地做出贡献，自觉地追求工作效益。
◆ 知识工作者的工作动力，取决于他是否具有有效性及他在工作中能否有所成就。如果他的工作缺少有效性，那么他对做好工作和做出贡献的热情很快就会消退，他将成为朝九晚五在办公室消磨时间的人。
谁是管理者
◆ 在一个现代的组织里，如果一位知识工作者能够凭借其职位和知识，对该组织负有贡献的责任，因而能对该组织的经营能力及达成的成果产生实质性的影响，那么他就是一位管理者。
《大教堂与集市》
Eric S. Raymond
1.好的软件作品，往往源自于开发者的个人需要。 按说这是显而易见的（正如老话说“需要是发明之母”），但太多的软件开发人员并不需要也不热爱他们正在开发的软件，他们把编程当差事，为的只是拿薪酬。Linux世界里可不是这样——也许这可以解释为什么Linux社区里原创软件的平均质量是如此之高。 2.优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。
《高效能团队模式：支持软件快速交付的组织架构》
马修·斯凯尔顿 曼纽尔·派斯
组织的沟通结构
◆ 2025/01/05发表想法
架构文档和组织结构图一样，当规模大了之后才开始显现其作用。
原文：软件开发真正开始的那一刻，软件架构文档就已经过时了一样，组织结构图也总是与现实脱节的。
选择团队拓扑需要考虑的因素
◆ 那些正在推广敏捷并向小批量交付转变的传统组织常常缺少成熟的工程实践，各团队在自动化测试、部署、监控等方面都难以保持长期、稳定的节奏。
◆ 明确的使命和截止时间
流动式团队
◆ 流动式团队是组织中最主要的团队类型，其他基本团队拓扑的目标都是为了减轻流动式团队的负担
◆ 现代软件开发组织中的大多数团队都应该是流动式团队，这将使得工作流清晰、待办事项明确，同时易于安排优先级。
◆ 与之相反的是按项目组织开发工作。一个项目来自某个客户的某方面需求，或者来自若干个客户的若干个小需求。在项目被批准后，若干个职能团队（比如前端、后端、DBA等团队）一起协作来实现它，工作被分解并填充到每个团队的待办任务列表中。
赋能团队
◆ 在Accelerate一书中，Forsgren、Humble和Kim告诉我们，高效能团队通过不断提高能力而保持领先。但是负责端到端的流动式团队总是工作在交付压力之下，需要快速交付和响应变化，哪有时间去调研、探索、学习和实践新技能呢？赋能团队由特定技术领域或产品领域的专家组成，可以由他们来提供帮助。赋能团队进行调研工作，尝试不同方案，并在工具、实践、框架、技术栈等方面给出高质量的建议。这使得流动式团队不必付出太多努力就能获得能力提升（根据我们的经验，这样的努力及其影响对团队其他成员来说往往会被低估10～15倍）。
平台团队
◆ 更糟糕的是，在2013年以前，软件开发项目的费用计入资本支出（CapEx），而IT运维工作的费用计入运营支出（OpEx），这使得开发团队和运维团队被人为地割裂了。根据要求，软件开发团队90%的精力必须放在资本支出上，于是他们别无选择，必须不断开发新东西，而没有精力修复问题和改进用户体验。开发团队不是为用户服务的，而是为产品管理层服务的。这种情况必须改变。
软件职责和边界中的团队优先方法
◆ 如果没有从团队的角度考虑，我们就有可能在错误的地方拆解单体服务，甚至创建一个由相互依赖的服务组成的复杂系统。这被称为“分布式单体系统”，导致团队缺乏对服务的自主权，因为几乎所有的变更都需要同时更新其他服务。
《数据工程之道：设计和构建健壮的数据系统》
乔·里斯 马特·豪斯利
第一部分 基础和构建块
◆ 一旦一项新技术碾过你，如果你不是压路机的一部分，那么你就是道路的一部分。
《程序员度量：改善软件团队的分析学》
Jonathan Alexander
第2章 测量程序员的工作
◆ 度量的第一个目的是帮助你跟踪和理解发生了什么。
◆ 度量的第二个目的是帮助人们沟通发生的事情。
◆ 度量的第三个目的是帮助人们关注那些他们真正需要改善的事情。度量记录了你所做和所完成的事情，并且给出了一个关于你的期望水平和实际水平的比较。
◆ 只有在度量作为每个程序员当前的工作技能、强项和弱项的反映，而不是作为一种评级方法的前提下，度量才真正有效。
◆ 相对“公平”的合同，这个合同往往会参照行业标准及其他拥有类似技能的球员的合同，现在许多体育合同的争论都引入仲裁这一独立的机构，通过比较程序来裁决出一份公平的薪水。在仲裁时，球员统计数据扮演着重要角色
◆ 更多的特性、更紧迫的进度和更高的质量三者之间做选择的话，你只能满足其中两个，而剩下那个将无法得到满足。
Go For It
又到了每年立Flag的时候了：
- C罗累计进球数超过1000个
- 零跑2026年销量超过100万辆
- AI领域中国会出现一家超过Manus的AI应用公司并且在26年发布一个Killer App
- 俄乌战争结束
以上就是给老板们，明星们，政要们立的Flag。
今年就不给自己立什么Flag了，想做的事情就去做吧，2026 Go For It!